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REMARKS/ARGUMENTS 

Status of the Application: 

Prior to entry of this amendment, claims 1-8 stand pending in the application. 
The office action dated March 12, 2003 rejected claims 1-8 under 35 U.S.C. § 102(e) as 
anticipated by U.S. Patent No. 6,230,164 (Rekieta). This response neither amends, cancels nor 
adds any claims. Thus, after entry of this amendment, claims 1-8 remain pending in the 
application. 

Rejections under 35 U.S.C. S 102(e): 

As noted above, the office action rejected all pending claims under 35 U.S.C. § 
102(e) as anticipated by Rekieta. The applicant respectfully traverses those rejections, however, 
and submits the following arguments in support of his position: 

The Rekieta reference fails to disclose each of the limitations of the claims and 
therefore cannot anticipate any of the claims under § 102(e). For instance, claim 1 recites, inter 
alia, that 

"the database is replicated a plurality of times, the database of one of said 
replicated databases is a primary database, the data control function of which is 
arranged to generate signals for synchronised updating of all of said replicated 
databases, and at least a second database is a primary standby database, the data 
control function of which is arranged to generate signals for synchronised 
updating of all of said replicated databases in the event of a failure of said 
primary database." 

Rekieta fails to teach or suggest these limitations. Although the office action does 
not analyze the Rekieta disclosure in detail, the office action's rejection of claim 1 refers to Fig. 
3 and column 5 line 5 to column 7 line 42 of Rekieta. The cited passage, however, nowhere 
discloses that a "database is replicated a plurality of times," with one of the databases being a 
"primary database" and "at least a second database is a primary standby database," as recited in 
claim 1. 
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Instead, the cited portion of Rekieta (col. 5, Ins. 5-13) discloses an arrangement 
using multiple SCP pairs, each of which is responsible for providing services for a portion of the 
subscriber database. Hence, the data in each SCP pair is different (a discrete portion of the 
whole database), and such portions therefore cannot correspond to the entire subscriber database. 
In fact, Rekieta (col. 5, Ins. 1-12) clearly teaches away from maintaining the entire database in 
each SCP pair: "By associating a portion of the subscriber database to each SCP pair 26, rather 
than the entire subscriber database , the response time of the SCPs is greatly increased." 
(emphasis added). (Presumably, the drafter of Rekieta meant to state either that responsiveness 
is increased or response time is decreased.) Consequently, since the each of the SCP pairs 
contains only a unique portion of the database, the multiple sets of SCP pairs do not represent a 
replicated database and cannot anticipate this limitation of claim 1 . 

Perhaps the office action's citation to Rekieta as disclosing a database replicated a 
plurality of times refers not to the multiple SCP pairs, but instead means that the portion of the 
database maintained within a particular SCP pair is replicated between each of the two SCPs in 
that pair. This interpretation of Rekieta fails as well to teach the limitations of claim 1, however, 
because Rekieta nowhere teaches or even suggests one SCP in a given pair being a primary 
database, with the other SCP being a standby database. Instead, Rekieta (col. 5, Ins. 50-52) 
appears to teach that each SCP is co-equal, such that "[a] database synchronization process is 
performed periodically and/or on demand between SCP 26a and 26b to update the respective 
copies of the SCPs with this transient data." 

Further, Rekieta nowhere teaches or suggests that one of the SCPs in a pair has a 
"data control function . . . arranged to generate signals for synchronised updating of all of said 
replicated databases," as does the primary database recited by claim 1 . Instead, according to the 
teaching of Rekeita (col. 13, In. 58 though col. 14, In. 17, whenever data in one SCP of the SCP 
pair is changed, an updating signal is sent to the other SCP. Thus, each SCP acts as a mate for 
the other, so they do not act as a primary and primary standby database. If data in one SCP is 
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changed that triggers change to the other SCP. It is not the case that one is primary. Therefore 
the SCPs of the SCP pair cannot be the replicated databases of claim 1. 

Notably, even if Reki eta's SCP pair arrangement somehow could be interpreted to 
teach the limitations of claim 1 (which it cannot), that arrangement still would fall far short of 
teaching the limitations of the dependant claims, including for instance, claim 2, which recites 
that "a plurality of databases are primary standby databases." If one member of the SCP pair 
were considered a primary database, the SCP pair would have only one other database-the other 
member of the pair-to be a standby. This arrangement cannot be interpreted to teach or suggest 
a plurality of primary standby databases as recited by claim 2. 

Even assuming that Rekieta taught a primary and a standby database (which, as 
discussed above, it does not) Rekieta fails to disclose claim 1 's limitation that "the data control 
function of [the standby database] is arranged to generate signals for synchronised updating of 
all of said replicated databases in the event of a failure of said primary database." In fact, 
Rekieta appears not even contemplate that one of the SCPs in a pair could fail, let alone discuss 
the operation of the system in the event of such a failure. The teaching of Rekieta fails in this 
regard similar to the failure of U.S. Patent No. 5,890,156, discussed in response to the previous 
office action. Thus, the SCP pairs cannot be considered to teach a primary and a standby 
database, as claimed in claim 1 . 

Rekieta (col. 6, Ins. 8-14) does teach that each SCP includes an "active platform 
manager" and a "standby platform manager," so perhaps the office action interprets the platform 
managers as teaching claim 1 's primary and standby databases. Rekeita's disclosure of the 
platform managers likewise fails to teach these limitations, however. Claim 1 recites that the 
replicated database "comprises] at least a data function and a data control function." The 
platform managers do not store data in this way. Instead, they rely on data stored in "shared 
memory" within each IPU. However, as is evident from Fig. 3 A, the IPUs are not replicated 
databases. Instead, each IPU stores a different subset of the entire database. Fig. 3 A then shows 
that if one of the EPUs fails, the data in it is transferred to other IPUs. Therefore, the IPUs are not 
the replicated databases of the present invention. Indeed, the data is replicated not between IPUs 
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but instead between a pair of mirrored memory storage devices 80 and 82. Thus the platform 
manager and standby platform manger of each SCP accesses unreplicated databases 60 to 64 
containing transient storage of data replicated in disks 80 and 82. 

However, the disks 80, 82 cannot correspond to the databases of the claim 1, 
because they do not act as a primary and a primary standby database. Indeed, there is no 
disclosure in Rekieta of what happens if one of the disks 80, 82 fail. Thus, in Rekieta the 
functions, represented by the Platform Manager and the standby platform Manager, are not 
replicated databases. They are simply processes which operate on data stored elsewhere. The 
data they use is taken from a series of unreplicated databases (the EPUs) which act as temporary 
storage for data derived from replicated disks 80, 82, which, again, reasonably cannot be 
interpreted to teach the databases of claim 1 because, inter alia, neither of the disks 80, 82 
represent a primary or primary standby database. The apparent intention of Rekieta is that the 
disks function at all times. Rekieta is concerned with the failure of individual IPUs, and the re- 
assignment of data from that failed IPU to other IPUs (they need the data from that failed IPU to 
be re-assigned since there is no replication of data within the IPUs). 

For at least these reasons, the disclosure of Rekieta fails to disclose each of the 
limitations of claim 1. For similar reasons, Rekieta fails to disclose independent claims 5 and 8, 
while dependent claims 2-4, 6 and 7 are allowable as depending from allowable base claims as 
well as being directed to specific novel substitutes. Hence, the applicant respectfully requests 
that the rejections under 35 U.S.C. § 102(e) be withdrawn. 
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CONCLUSION 



In view of the foregoing, Applicants believe all claims now pending in this 



/ Application are in condition for allowance. The issuance of a formal Notice of Allowance at an 
early date is respectfully requested. 



If the Examiner believes a telephone conference would expedite prosecution of 



this application, please telephone the undersigned at 303-571-4000. 



TOWNSEND and TOWNSEND and CREW LLP 

Two Embarcadero Center, 8 th Floor 

San Francisco, California 941 1 1-3834 

Tel: 303-571-4000 

Fax: 415-576-0300 
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Respectfully submitted, 



CnadE. KihgJ 
Reg. No. 44,187 
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